So after binding to NSBrowser selectionIndexPaths: https://developer.apple.com/library/archive/documentation/Cocoa/Reference/CocoaBindingsRef/BindingsText/NSBrowser.html this causes NSBrowser to do some weird stuff that seems completely unrelated to this particular binding. It starts calling NSBrowserCell methods on my cells but my cell is not a NSBrowserCell. My cell is actually a subclass of NSTextFieldCell. But NSBrowser starts sending setIsLeaf: (which I don't implement). In any case if I implement the -setLeaf: that solves that unrecognized selector, but now my cells don't draw titles. Not sure why binding to selectionIndexPaths causes this behavior? The cell stuff seems unrelated to this particular binding. I am of course using the newer but still pretty old item based APIs... do these bindings only support using NSMatrix? I do set the binding after calling -setCellClass: but makes no difference. I also just tried overriding -setSelectionIndexPaths: but NSBrowser does not use the setter.

So I'm working on adding another component to my app that uses NSOutlineView, as we do in AppKit. There will probably always be less than 25 rows here. One row is much larger than the others. Not sure if any of this matters. What I know is I noticed scrolling it is very jank. It's going way too fast. So I took a peek and see lineScroll is getting is 304 in Interface Builder. Not sure how that happened. I changed it to like 24. Then Interface Builder automatically changes it back to 304. So in -viewDidLoad I just set it: NSScrollView *scrollView = self.outlineView.enclosingScrollView; scrollView.verticalLineScroll = 24.0; scrollView.lineScroll = 24.0; But scrolling still is busted. So I subclass NSScrollView and override the setters. For some reason, NSTableView's -tile method is deciding to change the lineScroll to 304, all on its own. So every time tile is called. line scrolls get reset to 304.

There appears to be a data loss bug in NSFileWrapper on macOS 26.4. It may have been around longer but I just never noticed ... So I write a RTFD file wrapper: NSFileWrapper *rtfd = [attributedString RTFDFileWrapperFromRange:NSMakeRange(0, attributedString.length) documentAttributes:@{NSDocumentTypeDocumentAttribute:NSRTFDTextDocumentType}]; Now IF I use -writeToURL:options:originalContentsURL:error: without using the NSFileWrapperWritingAtomic option and I pass in an existing URL, the followings happens: -The method returns NO and populates the NSError with NSFileWriteFileExistsError, as expected. This is what I want. -BUT the existing file is nuked. It just disappears. Foundation kills it. Poof. Another thing I gotta workaround. Getting pretty ridiculous, I must say. Just my lucky day I guess. It would be wonderful if I could work on my own features and fixing my own bugs.

I have a Document based app. It supports different document types. One document type my app supports conforms to another document type that my app also supports. In my app these two UTIs are designated to open different NSDocument subclasses / window controllers. So say we have these two UTIs: com.DocumentType.SuperType com.DocumentType.SubType. Now I just noticed on Tahoe 26.4, the system is launching my app using NSDocument/window controller that is designated for com.DocumentType.SuperType, when I double click a file with the com.DocumentType.SubType UTI. I haven't changed the NSDocument configuration in many years but it looks like something changed recently.

In Interface Builder there use to be a segmented control to switch Inspectors. It's been this way forever. I could switch from: File Inspector Attributes Inspector Size Inspector Etc... Now in Xcode 26.4, it is this clunky pop up button? What? I thought Apple didn't like Interface Builder anymore so I'm surprised they are even touching it. This part of a SwiftUI rewrite or just bad vibes?

So if I have a selection in NSBrowser. I hit Option+Command+A to invoke "Deselect" the selection in the parent for the last column drops its selections, as expected. But the column doesn't drop off the browser. The delegate method (void)browser:(NSBrowser *)browser didChangeLastColumn:(NSInteger)oldLastColumn toColumn:(NSInteger)column NS_SWIFT_UI_ACTOR; Never fires (since the column isn't dropped off). But we have. dangling last column with no selection in the previous column. Now if there's enough room for me to deselect by clicking the background, the last column drops off, as expected. This seems to be fairly new? Anyone else experiencing this? These 26point updates seem to keep punching me in the face. And yes. deselect all seems somewhat broken in Column view in the Finder as well, but in a seemingly different way. In Finder it just seems to change the selection color like it deactivated the window but doesn't drop the selection. For me, the selection IS dropped but the column remains visible. Maybe they are using Cocoa bindings or something that resyncs the selection after the mess up. I dk.

The documentation for NSURL -URLByAppendingPathComponent: states: "Returns a new URL by appending a path component to the original URL." Path component is singular. But this "works" : NSURL *testURL = [applicationsDirectory URLByAppendingPathComponent:@"Evil/../../" isDirectory:YES]; So my questions are: One) Was it always this way? I can't recall if it was like this before the Foundation rewrite and I just never stumbled across? and Two) Is it intended behavior? The API seems to suggest that you append one path component on the url with this method. But I guess you can append as many as you want?

I use QLThumbnailGenerator to generate icons. After updating to macOS Tahoe 26.4 the folder color preference of the user is no longer respected. It just makes the icon default 'light blue.'

So I just installed the 26.4 update and unfortunately I have to debug this newly introduced issue (that may work its way into a separate thread). In my debugging steps I'm testing something related to files and I used -activateFileViewerSelectingURLs: to show the file in Finder. Now I am off the main thread. I added this line for testing purposes and I get a crash: NSWindow should only be instantiated on the main thread!' terminating due to uncaught exception of type NSException. So apparently - NSWorkspace is calling through to NSServices APIs and for some reason the system wants to present an NSError, which is a subtopic and other bug on its own because the 'Show in Finder" functionality actually WORKS but it crashed my app! #22in +[NSAlert alertWithError:] () #23in -[NSApplication(NSErrorPresentation) presentError:] () #24 +[NSServicesMenuHandler _performServiceFromEntry:withPasteboard:withRequestor:withInvocationSourceType:withCarbonFocus:withSendTypes:withReturnTypes:canReleasePasteboardImmediately:] () #25 +[NSServicesMenuHandler _performServiceWithoutAlternatesFromEntry:withPasteboard:withRequestor:withInvocationSourceType:] () #26 +[NSServicesMenuHandler _performServiceFromEntry:withPasteboard:withRequestor:withInvocationSourceType:] () #27 [NSWorkspace activateFileViewerSelectingURLs:] What error it is trying to present.. I have no idea. I'm not sure if I actually have a code path that calls this method off the main thread but I guess I'll have to check. This clearly goes against the documentation. NSWorkspace documentation clearly states: -activateFileViewerSelectingURLs: Discussion You can safely call this method from any thread of your app. Is this new in 26.4? I'm not sure but I just noticed. I definitely use other NSWorkspace methods off the main thread in areas of my app. Like -activateFileViewerSelectingURLs: the documentation for those other methods claims you can safely call them off the main thread. So now I'm concerned.

Sort of a continuation of - https://developer.apple.com/forums/thread/813641 I've made a great effort to get NSURL -getResourceValue:forKey: calls etc off the main thread. Great progress. So now I'm working with a file on a really slow network volume I discovered a little hang and luckily enough I'm attached to the debugger so I paused that thing. I see where I'm at. It is: NSPathControl's setURL:. It goes a little something like this: in realpath$DARWIN_EXTSN () +fileSystemRealPath () +[FSNode(SandboxChecks) canAccessURL:withAuditToken:operation:] () +FSNode(SandboxChecks) canReadFromSandboxWithAuditToken:] () LaunchServices::URLPropertyProvider::prepareLocalizedNameValue () LaunchServices::URLPropertyProvider::prepareValues () prepareValuesForBitmap () FSURLCopyResourcePropertiesForKeysInternal () CFURLCopyResourcePropertiesForKeys () -[NSURL resourceValuesForKeys:error:] () in function signature specialization <Arg[1] = Dead> of Foundation._NSFileManagerBridge.displayName(atPath: Swift.String) -> Swift.String () in displayName () -[NSPathCell _autoUpdateCellContents] () -[NSPathCell setURL:] () Could maybe, NSPathControl get the display name etc. asynchronously? and maybe just stick raw path components in as a placeholder while it is reading async? Or something like that? If I can preload the resource keys it needs I would but once the NSURL asks on the main main thread I think it will just dump the cache out, per the run loop rules.

Testing copyfile on a folder on an external volume (which takes a bit a of time) I'm running into an issue where copyfile gets to the end of the operation and then just fails. In the callback I can see that the failure occurs on a .DS_Store file inside the folder. So for a .DS_Store it is simple enough for me to just ignore the error and return COPYFILE_SKIP but the somewhat more concerning issue here is that the true error reason is seemingly not reported? In the callback if I read errno it is 0. When copyfile returns it returns -1 after I return COPYFILE_QUIT (and errno is 0) so I don't know what the error is or the appropriate way to handle it. For .DS_Store just skipping seems reasonable but when copying a folder it may be appropriate to get the true failure reason. But checking the last path component of source path seems like a hack way to handle errors. If a file in the copying folder with important user data I can't just silently skip it - it isn't clear to me how I should properly proceed in a situation where I can't get the actual reason for the failure.

So I'm in the middle of an asynchronous file operation. I publish an NSProgress and it displays wonderfully in Finder. But it is a folder and while the operation is in progress the user should not be allowed to enter it, modify it, etc, while the work is being done. I want to do this to protect the user from doing something silly. But Finder does not prevent the selection with the published progress. And while it would be kind of dumb to do - the user can just go about adding/removing contents to the folder while it has progress. If I remember correctly publishing an NSProgress did use to prevent the file from being selectable in Finder until either the progress finished or my app is quit (or maybe not)? But now the user is free to select, edit, modify during progress which could cause problems if the user does something unexpectedly silly. Is there a way to mark the file 'unselectable' with the published progress? Thanks in advance.

The man page of copyfile sates the following: COPYFILE_CLONE [..] Note also that there is no support for cloning directories" COPYFILE_CLONE_FORCE [...] Note also that there is no support for cloning directories: if a directory is provided as the source, an error will be returned. Now the man page for clonefile: > Cloning directories with these functions is strongly discouraged. Use copyfile(3) to clone directories instead. -- So am I to enumerate the content of a directory build subfolders along the way in the target destination and clone each file inside individually? If I recall NSFileManager seems to clone a large directory instantly (edit actually I remembered wrong NSFileManager does not do this. Finder seems to copy instead of clone as well). On further inspection, clonefile states that it can do this, but it is discouraged. Interesting. I wonder why. If src names a directory, the directory hierarchy is cloned as if each item was cloned individually. However, the use of clonefile(2) to clone directory hierarchies is strongly discouraged. Use copyfile(3) instead for copying directories. P.S. - Forgive me if I posting this in the wrong category, I couldn't find a "category" in the list of available categories on these forums that seems appropriate for this question.

So if I create an Alias of a folder in Finder and hand the alias to my app (I also moved the alias file to a new folder, but I did not move the original folder)...so then my app resolves the alias using: NSURL +URLByResolvingAliasFileAtURL: What happens? The resolved URL points to a completely different folder. Well not completely different. It resolves to a folder that happens to share same last path component as the original folder...but this folder is inside the same parent folder the alias file is in. It does not resolve to the original folder I created the alias of. So then once my app touches the alias with +URLByResolvingAliasFileAtURL: the alias now resolves to this new (wrong) location (even in Finder). Couple details: My app is not sandboxed. I have permission to access the original folder in my app (but even if I didn't the alias shouldn't be mutated just by merely resolving it). Only seems to happen if the folder I move the alias to happens to contain a sibling folder that has the same title as the original folder. Like it's just deleting the last path component of the alias and then appending the last path component of the original filename and just going with that. I hope that makes sense. I tried creating the alias myself using -bookmarkDataWithOptions: and going the other way (to Finder) but Finder must be resolving the alias using a different API because it resolves to the original location as expected.

When I end editing pressing the escape key, the system sometimes plays NSBeep(). I noticed this with NSBrowser. Every time I press escape to end editing the system beeps. At first I thought it was somewhere in my app but I set a symbolic breakpoint and discovered it was not coming from my code. I filed FB22127038. Since then I discovered that NSBeep playing at inappropriate times is not exclusive to NSBrowser. It appears if there is a NSTableView in the window and you just press the escape key (even if you aren't editing anything) AppKit beeps. It can be traced to: #0 0x0000000199e3184c in NSBeep () #1 0x000000019aa03fac in -[NSWindow doCommandBySelector:] () #2 0x000000019ac1d01c in -[NSTableView(NSTableViewViewBased) cancelOperation:] ()